AMENDMENTS TO THE SPECIFICATION 



Please amend the paragraph on page 5, hnes 31 and 32 as follows: 

Fig. 9 is a Figs. 9(1) and 9(2)1 are high level flowchart flowcharts showing the 
steps performed when the tax gateway 34 or 40 of Fig. 8 processes a merchant taxation 
request. 

Please amend the paragraph on page 5, lines 33 and 34 as follows: 

Fig. 10 is a Figs. 10(1) and 10(2) are high level fl o wchart flowcharts showing the 
steps performed for verifying and/or enhancing an address so that whenever possible at 
least four additional digits are added to the zip code. 

Please amend the paragraph on page 5, lines 35 and 36 as follows: 

Fig. 1 1 is a Figs. 11(1) and 11(2) are high level flowchart flowcharts showing the steps 
performed by the tax computing engine 70 (Fig. 8) when computing the tax(es) on merchant 
supplied sale transaction data. 

Please amend the paragraph beginning on page 33, line 20 and ending on page 34, line 24 
as follows: 

Figur e 9 describ e s Figures 9(1) and 9(2) describe the high level steps performed 
by the present invention when calculating the tax(es) on a customer 44 purchase of a 
product from a merchant enrolled with the network taxation system 32. Accordingly, in 
step 604 of Figure [9] 9(1) a merchant's e-commerce engine/server 86 commences 
processing a sale of a product to a customer 44. Note that instead of the sale being via the 
m e rchan t s merchant's e-commerce engine/server 86 wherein the customer 44 is remotely 
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linked to the merchant by the network 46, the customer 44 may instead be interacting 
with personnel for the merchant wherein the sales transaction information is entered into 
an off-line sales transaction system (as this term has been described hereinabove). Since 
in either case (i.e., whether the customer 44 purchases a product via the merchant's e- 
commerce engine/server 86, or the merchant's off-line sales transaction system), 
substantially the same steps are performed by the present invention whenever taxes are to 
be computed by a tax gateway 34 or 40. In step 608, the tax agent subsystem 48 (e.g., a 
tax gateway plug-in 82) is activated at the merchant's site for requesting tax calculation 
by a tax gateway 34 or 40. In particular, the tax agent subsystem 48 transmits sale 
transaction data about the sale to the tax gateway. Subsequently, in step 612, the 
merchant interaction control system 256 receives the sale transaction data. More 
particularly, the network interface and security 252A receives the sale transmission data 
via, e.g., a secure socket layer (SSL) and verifies that the sale transaction data is from an 
enrolled merchant. In one embodiment, such verification may be performed by the 
merchant permissions system 452. In another embodiment, such merchant verification 
may be performed by the merchant enrollment system 444. Regardless of which of the 
systems 444 and 452 are activated for performing merchant verification, such verification 
is performed by retrieving the (any) merchant's identification record and associated 
business rules (that the merchant has selected) from the merchant database 456. 
Subsequently, in decision step 616, the merchant interaction control system 256 uses the 
sale transaction data together with the m e rchan t s merchant's business rules for 
determining whether to calculate at least some transactional taxes, or provide only a 
verification (and/or enhancement) of an address for the customer 44 provided within the 
sales transaction data. Note that since some of the merchant's business rules may provide 
certain default types of processing for such sale transaction data, processes for 
implementing the merchant selected business rules will be performed unless: (a) the sale 
transaction data has information specifying altemative processing for one or more of the 
merchant selected business rules, and (b) such business rules permit such altemative 
processing. Thus, a merchant may select as a business rule that all sale transaction data 
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instances received by the tax gateway 34 or 40 should have all applicable taxes computed. 
However, the merchant may specify in a given instance of sale transaction data that no 
taxes are to be calculated, and instead, only the customer's address is to be verified. 
Further, note that the present decision step of 616 may be performed through the 
activation of the GUI controller 436A when the sale transaction data (or instance thereof) 
is provided interactively via the merchants network browser 52, or interactively via some 
version of the tax agent subsystem 48 which is used as an adjunct to the merchants off- 
line sales transaction system. Alternatively, decision step 616 maybe performed 
independently of the GUI controller 43 6 A when an instance of the sale transaction data is 
provided automatically via the tax gateway plug-in 82. 

Please amend the paragraph beginning on page 34, line 25 and ending on page 35, line 5 
as follows: 

If, in step 616, it is determined that only address verification need be performed 
for the present instance of sale transaction data, then step 620 is performed. In this step: 
(a) the appropriate attributes/value pairs of the network 46 transmitted sale transaction 
data instance that are related to address data to be verified, and (b) the appropriate 
merchant business rules related to address verification are used to activate the address 
verification system 448 for thereby verifying and/or correcting one or more addresses in 
the sale transaction data instance. Note that further detail as to how address verification 
is performed is described herein below in reference to Figur e 10 Figures 10(1) and 10(2) . 
However, it is worth mentioning here that various levels of address verification may be 
performed depending on the address input of the attribute/value pairs and the merchant's 
business rules. Thus, a merchant may request that only an address status be returned 
indicating whether an input address is valid or invalid. Alternatively, the address 
verification system 448 may return one or more statuses indicating the likely validity of 
certain address fields within an address. Additionally, substitute addresses may be 
provided in certain contexts as will be discussed hereinbelow regarding Figui 'c 10 Figures 
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10(1) and 10(2) . Subsequently following step 620, the address verification results are 
returned to the requesting merchant in step 624. Then, in step 628 the merchant 
interaction control system 256 prepares for receives a next merchant request to process. 
Thus, when a next merchant request is received, step 612 is again performed by the 
merchant interaction control system 256. 

Please amend the paragraph on page 35, lines 6-20 as follows: 

Referring again to step 616, if it is determined that at least some taxes are to be 
calculated for the present instance of the sale transaction data, then step 632 is performed 
wherein the tax computing engine 70 is activated with (the appropriate portions of) the 
merchants request and the merchant's business rules for thereby performing and/or 
collecting taxes for the purchase to which the current instance of the sale transaction data 
corresponds. Note that the processing performed in the present step is further described 
hereinbelow and in the fl o wchart of Figur e 1 1 flowcharts of Figures 11(1) and 11(2) . 
Subsequently, in decision step 636, the tax computing engine 70 determines which (if 
any) taxes are to be collected by the network taxation system 32 of the present invention. 
If no taxes are to be collected, then step 640 is performed wherein the information related 
to any tax(es) calculated by the tax computing engine 70 is returned to the merchant. 
Additionally, in step 644 (which may be performed prior to or substantially concurrent 
with step 640), the tax computing engine 70 stores in the tax audit archive 476 a tax 
record having the tax(es) (if any) calculated and an indication that such taxes were not 
collected. Subsequently, in step 648, the merchant interaction control system 256 
receives a next available merchant transaction to process. Thus, once such a merchant 
request is received, step 612 is again performed with this new request. 

Please amend the paragraph beginning on page 35, line 32 and ending on page 36, line 36 
as follows: 
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Referring now to Figure 10, t his figu r e describes Figures 10(1) and 10(2\ these 
fi|gures describe the high levels steps performed by the address verification system 448, 
Accordingly, in step 704, the variable ADDRSS_LIST receives as its value a list of all 
addresses to verify fi-om the merchant request data provided to the address verification 
system 448 by the merchant interaction control system 256 (e.g., via step 620 of Figure 
[9] 9(1}). Subsequently, in step 708, the first address to be validated in the address list of 
ADDRSS_LIST is assigned to the variable ADDRS for subsequent processing. Note that 
in at least some embodiments of the present invention, ADDRSS_LIST references only a 
single address to be verified and/or enhanced. In particular, the tax agent subsystem 48 at 
a merchant node 50 may specify the one or more addresses to verify and/or enhance. 
Thus, at least some versions of the tax agent subsystem 48 may include tax processing 
capabilities sufficient to determine which of one or more addresses supplied by a 
customer 44 and/or the merchant is to be transmitted to the present invention for use in 
determining taxes. Further note that in one embodiment, addresses may be enhanced to 
provide zip+four as described hereinabove. Subsequently, in step 712, the address 
verification system 448 activates the zip code enhancement system 460 for thereby 
enhancing the address corresponding to ADDRS to a zip+four address. Note that the zip 
code enhancement system 460 may use a commercially available database system of 
which there are a number of providers or vendors for such address enhancing capabilities. 
In particular, it is preferred that the zip+four address enhancement capabilities of the 
present invention be certified (at least in the United States) by the United States Postal 
Service Coding Accuracy Support System (CASS), as one skilled in the art will 
understand. Subsequently, in decision step 716, a determination is made as to whether 
the address of ADDRS was processed successfully in step 712. If so, then step 720 is 
performed wherein a status field is set which indicates that the input and address and/or 
the enhanced version of the input address appears to be valid. Note that depending upon 
the merchant's business rules, and the subsequent processing to be performed after 
address verification and enhancement, different outputs may be provided by the present 
flowchart. For example, the original input address of ADDRS may be output with merely 
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a status field indicating whether the address is vaUd or invalid, or the enhanced address 
may be output (as a new value for ADDRS) wherein the status field indicates that 
ADDRS contains a valid address. Subsequently, in decision step 724, a determination is 
made as to whether the merchant's business rules allow for the processing of another 
address and additionally a determination is made as to whether there is another address to 
be processed that is referenced by ADDRSS_LIST. hi particular, note that an address to 
which a customer wishes a purchased product to be delivered may be different fi"om an 
address to which the customer desires to be billed, and if the merchant's business rules 
may specify that without further instruction within an instance of sale transaction data, 
that only the address where the product is to be delivered should be used for tax 
calculation purposes, then it may be possible for one or more addresses on 
ADDRS S_LIST not to be processed for address verification and/or enhancement. 
Accordingly, if there are no other addresses to be verified and/or enhanced, then step 728 
is performed wherein the addresses of ADDRSS_LIST are returned together with a status 
field for at least each address processed, wherein the status field indicates whether the 
(possibly enhanced) address therein is valid. Alternatively, if in step 724, it is determined 
that there are additional addresses to be processed, then step 708 and subsequent steps are 
performed with the next address from ADDRSS_LIST that is consistent with merchant's 
business rules. 

Please amend the paragraph beginning on page 38, line 8 and ending on page 39, line 20 
as follows: 

Figure 1 1 pr o vid e s Figures 1 l(l) and 1 1(2) provide many of the high level steps 
performed by the tax computing engine 70 for calculating taxes on an instance of sale 
transaction data received fi"om a merchant. ]n particular, the steps of Figure 11 Figures 
11(1) and 11(2) are performed when step 632 of Figure [9] 9fl) is encountered. 
Accordingly, in step 804 of Figure [11] 11(1) , the tax computing engine 70 receives sale 
transaction data input fi-om the merchant interaction control system 256 about a taxable 
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merchant transaction. In particular, the following information is supplied to the tax 
computing engine 70: the merchant's network taxation system 32 identification (i.e., ID), 
the classifications of the products (which includes services herein) purchased (i.e., such a 
classification may be the product code as defined hereinabove), one or more addresses 
related to the purchase, and optionally, for each line item of products being purchased, the 
following information may also be provided if available: a stocking unit identification 
(SKU), the quantity of the product being ordered, and the "extended price" (i.e., the unit 
price times the quantity of the product). Further, note that the one or more addresses 
received as input to the tax computing engine 70 may be the customer's location (address 
and zip code if available), the address of where the purchased product(s) is to be 
delivered, and/or the customer's billing address. Subsequently, in step 808, a 
determination is made as to whether the current input to the tax computing engine 70 is a 
request to finalize the tax(es) for a purchase wherein the tax(es) was determined in a 
previous activation of the tax computing engine 70. In particular, note that it is an aspect 
of the present invention to determine (if so instructed) taxes on a particular purchase via a 
two step process, wherein a first transmission of sale transaction data is provided to the 
tax gateway 34 or 40 for determining tax(es) without finalizing the tax determination, and 
subsequently performing a second step of finalizing the transaction and thus, the tax(es) 
calculated for the purchase in response to a second transmission fi-om the merchant. Note 
that a tax calculation is not finalized according to the present invention unless it is 
calculated and at least the results stored in the tax audit archive 476. Additionally, note 
that such a sales tax determination is also not finalized if the merchant's business rules 
indicate that the determined tax(es) (or a portion thereof) are to be collected and no such 
processing for collection (e.g., via the tax transactions database and management system 
472) has been performed. Accordingly, under certain conditions, the merchant may elect 
to have the taxes on a purchase calculated and returned to him/her without any fiirther 
steps being performed for finalizing the sales tax for the transaction. Thus, the merchant 
may subsequently provide another transmission of sales transaction data corresponding to 
the same transaction so that the tax gateway 34 or 40 may then finalize the tax process. 
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This two-step approach to finaHzing taxes is particularly beneficial for e-commerce sales 
transactions performed on the network 46 in that it is well known that a substantial 
number of potential purchases of products by customers 44 may be aborted or abandoned 
after substantially all price determinations have been performed. Accordingly, using this 
two-step approach to finalizing sales taxes allows the merchant to provide a total 
purchase price, including tax(es), to a customer 44 prior to finalizing the tax(es) for the 
transaction. Thus, once the customer has actually committed to a purchase, then the 
merchant can effectively retransmit the sales transaction data for the purchase so that the 
tax(es) calculated by the preceding process can be finalized. Accordingly, in step 808, a 
determination is made as to whether the current input to the tax computing engine 70 
corresponds with the second step of the two step finalization of tax(es) on a purchase. If 
the present input is indeed a request for finalizing a previously computed tax(es), then 
step 816 is performed wherein the previously computed tax results are retrieved firom a 
run-time database utilized by the tax computing engine 70. Subsequently, in step 820, the 
retrieved one or more records for the previously computed taxes (these records denoted 
here as the "tax levied records") are used to create persistent tax records for archiving in 
the tax audit archive 476, and additionally, if the merchant's business rules specify, 
collecting at least some portion of the taxes calculated. Subsequently, in step 824, data is 
output fi"om the tax computing engine 70 indicating the processing that has been 
performed, which in the present context is the finalizing the taxes on a purchase. 
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